panic: fix faulty panic handling - #1214
Conversation
lgirdwood
left a comment
lgirdwood
left a comment
There was a problem hiding this comment.
Sorry, I have no idea what bug you are trying to fix without a commit message. You must explain the issue and how your patch fixes the issue.
ae9c54d to
9bfab70
Compare
|
@lgirdwood sorry, fixed |
lgirdwood
left a comment
lgirdwood
left a comment
There was a problem hiding this comment.
Don't we need an update to core-dump.sh given we are changing order ?
This commit will change the order of functions in panic_rewind() to fix SOF_IPC_PANIC_STACK in dump_stack(). Thats because arch_dump_regs() function is not able to make a 100% safe return Signed-off-by: Adrian Bonislawski <adrian.bonislawski@linux.intel.com>
9bfab70 to
8570a31
Compare
|
@lgirdwood its not needed because from the reader point of view everything is exactly the same. Struct positions and offsets are the same, thats why now in line 65 there is a place for sof_ipc_dsp_oops_xtensa struct which will be filled later by arch_dump_regs() and thats the only thing which changed - the order of data processing, not their positions in memory. |
|
@abonislawski can you give CI a quick check, seems like a build is pending. |
|
@lgirdwood there was a need to do rerun of PRs from last night so we need to wait for them to reschedule to only then run PR tests for this day |
3 participants
This will fix SOF_IPC_PANIC_STACK in dump_stack()
This commit will change the order of functions in panic_rewind() to fix SOF_IPC_PANIC_STACK in dump_stack().
Thats because arch_dump_regs() function is not able to make a 100% safe return which is causing a problem for dump_stack()
Signed-off-by: Adrian Bonislawski adrian.bonislawski@linux.intel.com